…f()`

Co-authored-by: Corey Innis <[email protected]>

This change also includes:

- Renaming the `self()` type as `subject()`, to avoid confusion with Elixir's native `self()`.
- Addition of `ChannelOwner.bind!/3`, a helper for calls to `Channel.bind/4`.
- Some minor test tweaks for further clarity.

Co-authored-by: Ryan Spore <[email protected]>

Co-authored-by: Corey Innis <[email protected]>

Co-authored-by: Ryan Spore <[email protected]>

Co-authored-by: Corey Innis <[email protected]>

Co-authored-by: Ryan Spore <[email protected]>

Co-authored-by: Corey Innis <[email protected]>

Co-authored-by: Ryan Spore <[email protected]>

Co-authored-by: Corey Innis <[email protected]>

Co-authored-by: Ryan Spore <[email protected]>

Co-authored-by: Corey Innis <[email protected]>

Co-authored-by: Ryan Spore <[email protected]>

Co-authored-by: Corey Innis <[email protected]>

Co-authored-by: Ryan Spore <[email protected]>

…f()`

This change also includes:

- Renaming the `self()` type as `subject()`, to avoid confusion with Elixir's native `self()`.
- Addition of `ChannelOwner.bind!/3`, a helper for calls to `Channel.bind/4`.
- Some minor test tweaks for further clarity.

We've switched to the more idiomatic `t()` for function specs.

The `ChannelOwner.post!/3` implementation was problematic in (at least) the following ways:

- It resulted in a somewhat inheritance-like implementation and usage, w/out any need for that;
- It did not handle well differences between "posts" that should result in updates to the "subject" resource vs. retrieval of related resources;
- It did note handle well cases in which the "subject" **should not** be refreshed.

These shortcomings required multiple work-arounds and code verbosity. The introduction of `Channel.post/3` feels much cleaner, more manageable, and idiomatic.

This change provides part 1 of changes in support of pipelining API functions: where functions without the `!` suffix might return `{:error, error}`, those with the `!` will raise a `RuntimeError`.

Note that the underlying implementation is essentially a copy of that found in [`Unsafe`](https://github.com/whitfin/unsafe/tree/main). Minor adjustments have been made to integrate more closely with Playwright, and match desired usage and execution patterns.

An initial usage, for demonstration purposes, may be found at `BrowserContext.add_cookies/2`.

In support of easing the task of locating where to discover or add tests, the filesystem structure for the tests should match that of the implementation.

Note that this change introduced some sort of test pollution. That is resolved via additional cleanup performed `on_exit` as specified in `PlaywrightTest.Case`.

`Playwright.launch/2` now returns a tuple that includes `session`. This, in turn, may be passed to the newly implemented `Playwright.request/1`, which returns an instance of `Playwright.APIRequest`.

`APIRequest` implements `new_context/2` and `new_context!/2`, which create instances of `Playwright.APIRequestContext`.

Really, remove a bogus module, and ensure API modules grouped in API documentation section.

Including:

- `APIRequestContext.fetch/3`
- `APIResponse.body/1`
- `APIResponse.dispose/1`
- `APIResponse.header/2`
- `APIResponse.json/1`
- `APIResponse.text/1`

Also, removes:

- `APIRequestContext.body/1`. The function has moved to `APIResponse`, where it belongs.
- `APIRequestContext.post/3` for the time being; it needs to be TDD'd and the implementation should simply call `APIRequestContext.fetch/3`.

Incidentally, the placeholder for `Tracing` has been moved to `Playwright.Tracing`.

...where `<method>` is each of:

- `delete/3`
- `get/3`
- `head/3`
- `patch/3`
- `post/3`
- `put/3`

Note that this change depends on an updated `playwright-assets` dependency. v1.44.1 of that library adds HTTP response headers that we need here.

A "WIP" change... still need to implement the (optional) saving and reading of state to/from disk.

Incidentally, also:

- Add more function documentation, including "usage", to `APIResponse`
- Add test of `APIRequestContext.fetch/3` to cover default HTTP method (i.e., "GET")

This fix deserves better test coverage and implementation guards.

However, the function is not yet implemented. A single event is supported in Playwright proper: `disconnected`. And, the event is meant to be emitted from the client-side, upon `Browser.close/1`; we don't yet have a good mechanism for that.

Also, some cleanup.

It's the newly "patched" (co-dependent w/ its related `BrowserContext` that needs to be returned.

Warning:

this function has not yet been successfully tested.
  > So far, the test runs have failed to receive location data and instead
  > experiences "error code 2", which [reportedly](https://developer.mozilla.org/en-US/docs/Web/API/GeolocationPositionError/code)
  > represents `POSITION_UNAVAILABLE` - "The acquisition of the geolocation
  > failed because one or several internal sources of position returned an internal error."